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(54) Abstract Title 

Telephone based payment system 

(57) A generic payment system is based on the use of mobile 'phones and a payment server which stores 
details of a donor account and a beneficiary account, each account being identified by an account number. 
When a payment is to be made, the donor (who is going to make the payment) uses their mobile telephone to 
set up a communications link, via a mobile network, to the payment server. The Calling Line Identity of the 
donor's telephone is passed to the server to uniquely identify or authenticate the telephone to the server. 
Information enabling a transaction between the donor account and the recipient account is then sent over the 
communications link to the server. The server may optionally contact the beneficiary, using their mobile 
telephone, to inform them of the payment. In alternative embodiments the authentication of the donor or the 
donor's telephone may be achieved by transmission of a Personal Identification Number or a voice print. 
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Telephone based payment system. 



1 



Background 



1.1.1 



Ubiquitous powerful personal telephones 



The invention relates to a telephone-based payment system, and in 
particular to a mobile telephone based micro payment system. 

Mobile 'phones have become ubiquitous in modem society. Many 
users carry and rely upon their mobile 'phone as much as a wristwatch 
or wallet Moreover contemporary mobile 'phones contain almost as 
much computer (CPU) power as many PCs. These facts have led some 
commentators to argue that mobile 'phones will become a 
commonplace method of accessing the Internet and thus of making 
transactions. 



The mobile telecoinmunicatioi\s industry has catered to this demand, 
amongst other ways, by the development of "mobile Internet" i.e. 
simplified versions of the original wireline based Internet designed to 
acconunodate the Umited display screen size and limited 
communication bandwidth between the 'phone and the network. WAP 
(Wireless Application Protocol) is the best known of the mobile 
Internet standards. Mobile Internet follows the same principles as 
regular Internet namely that information is published on a Web site / 
WAP-site and any one with a compatible Web / WAP browser can 
access this site over the Internet. As happens on the fixed Internet 



1.1.2 



Mobile Internet 



1 



12/20/2008, EAST Version: 2.3.0.3 



users may make purchases or other financial transactions over the 
Mobile Internet. 

However while mobile Internet follows the same general philosophy 
as fixed Internet there are important differences that limit its utility 
and therefore likely uptake. WAP is not compatible with HTML (the 
language of the fixed hitemet) and therefore WAP 'phones cannot 
access any of the vast number of existing HTML based sites and a 
selling Merchant must create and publish a WAP site. Moreover 
many existing subscribers do not currently have WAP capable 'phones 
and even on those 'phones that do offer WAP, the user may have to 
have substantial skill and patience to use it. It can be complex, tedious 
and cumbersome to navigate through the 'phone's menu functions to 
locate and select the WAP option, establish a dial-up coimection, recall 
or search for the target WAP site address, browse to that site, locate die 
product in question and then browse to the payment page, enter 
payment details etc. 

1 • 1 -3 Premium Rate numbers/Automatic Vending 

Another well-known approach to telephone based commerce is the use 
of Premium Rate telephone numbers. These operate by charging a 
premium tariff for calls made to selected numbers e.g. to a stock 
market information service. This premium call tariff is charged to the 
caller's telephone bill and collected by the telephone network operator 
and the revenue for this call is split between the telephone company 
and the called party, i.e. the provider of Hie telephone information 
service. The advantage of this system is that it is very simple and 
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especially that the Merchant who provides the telephone iiaformation 
service does not need to have a billing relationship with the end-user. 

Premium Rate numbers were originally used in general purpose 
telephone applications i.e. a Premium Rate information service could 
be called either from a fixed or a mobile telephone. More recently 
Premivim Rate based services have been provided targeting only 
mobile users. These are used to provide Automatic Vending 
applications. 

The known Automatic Vending approach using Premium Rate 
numbers is illustrated in figure 1, and operates as follows. Each item 
in the vending machine 160 is given a different premium rate 
telephone number. The tariff rate for the premium rate call is set to 
correspond to the price of the item. To purchase the item the user dials 
the number on his mobile terminal 10. The number connects to a 
central facility that communicates with the vending machine and 
instructs it to dispense the item. The mobile 'phone user incurs the 
cost of the premium rate telephone call. The mobile Operator collects 
the charges for this bill from the user and passes the cost of the 
premium rate call to the Operator of the Premium Rate telephone. The 
Premium rate Operator remits to the Vending Machine Operator the 
price of the item purchased. 

While it would be technically possible to purchase an item from an 
automatic Vending machine from a fixed 'phone this would be 
unlikely in practice because there may not be a fixed 'phone close to 
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the Automatic Vending machine and if there were the person 
responsible for the 'phone biU may be unwilling to bear the cost of the 
items purchased. 



Two of the key feature of the Premium Rate number approach are that: 

• The service may be implemented independently of the Mobile 
Network Operator i.e. without their consent or co-operation. 

• There is a fixed correspondence between the Premium Rate 
telephone number and the amount payable. 

Intelligent Network Technology 

Premium Rate telephone number services are often implemented using 
Intelligent Network techniques. This section gives a brief summary of 
Litelligent Network using the same reference numerals as in figure 1. 

An "InteUigent Network" is one where the processing of a telephone 
call can, to a limited extent, be controlled by an external computer 
caUed a Service Control Point (70). The elements of an Intelligent 
Network are the Service Switching Point SSP 50, which physically 
connects the call, and the Service Control Point 70, which in some 
circumstances, governs the destination to which the call is connected. 
The SSP and the SCP are connected by a defined interface protocol (60) 
called the InteUigent Network AppUcation Part. Not all calls 
processed by ihe SSP will be referred to the SCP, only those that satisfy 
various triggering criteria. Calls to the SCP may be triggered by a 
number of conditions including: the identity of the caller, the number 
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dialled by the caUer etc. Intelligent Network architectures are 
commonly used to implement "digit translation" services such as 
Premium Rate, Freephone, Corporate Numbering Plans, etc. In a 
standard Telephone call the cost of the call is based on the called 
number, the time of day and the length of the call. The Intelligent 
network allows the call to be tariffed on other factors. For example. 
Premium Rate aUows the cost of the call to be based on the value of the 
information accessed rather than simply the cost of the telephone 
connection and Freephone allows the cost of the caU to be charged to 
the called party rather than the calling party. In the case of the 
Premium Rate service the originating telephone exchange (known in 
the art as the Service Switching Point or SSP) analyses the dialled digits 
and recognises the first few digits of the dialled number as those of a 
Premium Rate 'phone number. This triggers a request via the 
InteUigent Network AppUcation Part (INAP) signalling protocol to the 
separate computer known as the Service Control Point (SCP). The 
request contains the Identity of the Calling telephone Line (Calling 
Line Identity, CLI), and the digits dialled by the user. The SCP 
corwults its database and tratwlates the Premium Rate number dialled 
by the user into the geographic telephone number of the physical 
location of the destination. It returns this new telephone number to the 
SSP and instructs it to out dial that number. It also instructs the SSP to 
modify the CaU Details Record produced by the SSP to indicate that 
the caU should be charged at a Premium Rate. 
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1 ■ 1 -5 SIM Application Toolkit Techinology 

Another technique used to make payments from mobile 'phones is the 
use of SIM Application Toolkit (SAT) technology. This hke WAP is 
based on the client-server computing paradigm but rather than 
employing client software in the handset it employs chent software in 
the SIM card. The SIM card is a microprocessor-based secure smart 
card and is used inside all GSM mobile 'phones. The original and 
primary purpose of the SIM card is to stores confidential subscriber 
account information securely and to encrypt and exchange this 
information with the mobile 'phone network at the start of each call. 
This secure exchange of identity informatian allows the cost of the call 
to be debited from the correct account SAT can exploit the fact that 
the SIM is a standalone microprocessor, independent of the mobile 
'phone in which it is installed, and the fact that the SIM can provide 
security services, authentication and encryption of data. SAT extends 
the basic capabilities of the SIM card by allowing small software 
applications, e.g. an online banking application, to be downloaded to 
the SIM. The user selects a SAT option from a menu or special button 
on their 'phone and then selects, for example, the online banking 
service from the list of installed SAT applications. The user may then 
perform a banking transaction e.g. transfer funds between accounts, 
and the SIM card will send this transaction instruction through the 
mobile network to the banking application server. This transaction 
insh-uction is encrypted using the SIM card's encryption capabiHties. 
The main advantage of this system is that the SIM card communicates 
in a secure link directiy with the bank server. The bank can thus be 
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confident that only authentic, authorised users can perform 
transactions and that these users cannot repudiate any transactions 
they have actually made. 

1.1.6 Transferring Billing Records from other systenns. 

Most phone networks have billing arrangements with other domestic 
and foreign networks. A mobile phone network may be directly 
connected to other fixed and mobile networks in the same country. 
When a user on one network caUs a user coimected to another 
network, the call is handed over at an interface between the networks. 
Both the originating and terminating networks receive payments for 
handling their part of tihe call. The terminating network bills the 
originating network and the originating network bills the calling user. 
The billing mechanism between the Operators is normally in the form 
of a tape or file of Call Detail Records. 

Similarly most mobile phones have billing arrangements with foreign 
or international mobile 'phone companies. Many contemporary digital 
mobile cellular systems are internationally standardised and may be 
used in many different countries. This international usage requires 
both technical and commercial prior arrangements. 

As well as providing a common air-interface standard, the technical 
standardisation bodies (e.g. ETSI, GSM) have also defined technical 
procedures that allow users "roaming" abroad to be authenticated and 
to have records of calls (Call Detail Records) to be sent back to the 
user's Home network. The user's home network operator may then 
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calculate the cost of the caUs made and add these charges to the user's 
biU. 

The authentication mechanism is that the Home network can forward a 
series of "authentication triplets", which are in effect a set of one-time- 
use passwords. In this way, the Home network supplies a series of 
"ChaHenges" and pre-calculated expected correct "Responses". The 
visited network chaUenges the roaming mobile with the Challenge 
supplied by the Home Network and if the mobile replies with the 
correct expected response then it is deemed to be authentic. The 
Visited network may then aUow the call to proceed. There are also 
additional mechanisms used for users who have "pre-paid" accounts. 
These mechanisms require a more real-time contact between the 
visited and Home network, to ensure that the would-be caUer stiU has 
sufficient credit in their pre-paid account before the caU is permitted to 
begin. 

At the end of a suitable billing interval (this might be either hours or 
weeks) the Operator of the visited network collects the CaU Detail 
Records of caUs made by visiting roaming users and despatches these 
to their respective Home Operators. 

The billing systems of the Home ceUular operators are designed to 
accept these roaming billing records and to add the charges to the 
user's bill. 

To date these roaming billing mechanisms have been used only for the 
settlement of international (or domestic) roaming calls. 

8 
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2. 



The Invention: 



2.1 Overview 

The invention provides in its various aspects a telephone payment 
apparatus and method as defined in the appendent claims, to which 
reference should now be made. Preferred or advantageous features of 
the invention are defined in dependent subclaims. 

The invention may thus advantageously provide a Generic Payment 
System based on using digital mobile 'phones such as those employing 
the GSM standard. The 'phone may be a basic handset or employ 
special capabilites such as WAP or those found on a mobile Personal 
Digital Assistant (PDA). 

Embodiments of the invention will now be described by way of 
example with reference to the drawings, in which; 

Figure 1 shows a.prior art system for payment using premixma 
numbers; 

Figure 2 shows a payment system according to a first embodiment of 
the invention; 

Figure 3 shows a web page for making a payment according to a 
further embodiment of the invention; 

Figure 4 shows a payment system according to a further embodiment 
of the invention; 
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Figure 5 shows a payment system embodying a further embodiment of 
the invention incorporating an adjunct switch; 

Figure 6 illustrates direct and indirect authentication in a payment 
system embodying the invention; and 

Figure 7 iUustrates a web page offering a choice of payment methods, 
including mobile phone payment. 

The foUowing example, as shown in figure 2, illustrates one aspect of 
the invention. The embodiment allows one mobile 'phone user (the 
donor) 51 to pay another (the beneficiary) 52 by dialling over the 
mobile phone network 53 the following: 

• a Payment- Service Service- Access-Code 54 and, 

• the beneficiary's mobile telephone number 56, and, 

• an amount to be paid 58 and, 

• an (optional) PIN number (personal identification number). 

This action debits the sum from the donor's account 61 and credits it to 
the beneficiary's account 62. Both the Donor's and Beneficiary's 
accounts may be either their existing mobile 'phone account or their 
optional standalone account on a Payment Server 64. 

This embodiment works as follows. Rather than employing client 
software in the 'phones themselves, as WAP and SAT do, the 
embodiment employs inteUigence in the network. When the mobile 
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telephone network analyses the dialled number to decide how to route 
the call to its destination, it recognises the first three digits, e.g. 729 
(PAY) or 746 as a Service Access Code and "triggers" a request to a 
Payment Server. The request includes the digits dialled i.e. identifying 
the intended Beneficiary such as their telephone number or account 
number, the sum payable and optionally a PIN number. The request 
also includes the Calling Line Identity of the calling mobile 'phone. 
The Payment Server verifies that the PIN number (if present) is correct 
and if so transfers the specified amount of money from the Calling 
Party's Account to the Beneficiary's Account. The Payment Server can 
also be configured to send the Beneficiary a Short Text Message (SMS) 
or Voice Clip to verify that the payment has in fact been credited to 
their account. 

Figure 3 illustrates a second embodiment of the Invention. The 
embodiment allows a mobile 'phone user simultaneously to log onto a 
web site and to pay a (probably small) sum of money, for access to the 
web site. The embodiment provides an alternative to the traditional 
method of entering a user-name and password 71 to log onto a site, 
and enables a payment to be made. As shown in figure 3, the web site 
displays the Payment System Service Access Code (e.g. 729 or 746) 54, 
a reference number for that Web site 73 and optiorially a placeholder 75 
for the user's PIN nimiber. When the user dials this number on their 
mobile 'phone, the mobile telephone network analyses the dialled 
digits and identifies the first three digits, e.g. 729, as the Payment 
System Service Access Code and triggers a request to the Payment 
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Server. This request contains the caller's own telephone number 
(Calling line Identity), the Web site reference number and optionally 
the caller's PIN number. The Payment Server then checks the caller's 
credit and if sufficient transfers the money from the caller's account to 
the web-site account. It then uses the Web site reference number to 
identify the target web site and to inform it of the caller's identity, that 
the caller is authentic and that the money has been credited to the Web 
site's accoimt. 

This approach has advantages over the conventional user- 
name/ password method, including the following: 

• The user does not need to remember multiple individual user- 
names and passwords for individual Web sites but can access all 
participating Web sites with their mobile 'phone and a single PIN 
number. 

• It allows the log-on to be simultaneously combined with the 
payment of a small sum of money, which is debited from the 
Caller's mobile 'phone account or independent Payment System 
Account. 

Some of the key features of this aspect of the Invention, which can be 
appreciated from these embodiments, are: 

• It operates with basic mobile 'phone handsets and does not require 
the use of advanced second or third generation SAT (or STK) / 
WAP /UMTS handsets. 

12 
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• It is a generic payment mechanism which allows payments to be 
made to an arbitrary destination and of an arbitrary amotmt. This 
contrasts with premium rate based methods that offer payments of 
fixed amotmts to fixed beneficiaries. 

• It may be used in both online and offline situations. 
2.2 Further Detailed Description 

Further aspects of the Invention will now be described in more detail 
with the aid of figure 4 where the following elements are illustrated: 

2.2.1 Elements illustrated in figure 4 

(10) and (20) are mobile 'phone terminals. Users use these to access the 
mobile 'phone network 22, make and receive telephone calls, access 
data services, send and receive short text messages etc. 

The mobile 'phone terminals access the mobile 'phone network. The 
purpose and function of each of the elements of this network are well 
known to those familiar with the art. These are summarised briefly 
below. The mobile network comprises radio Base-Stations (30), Base 
Station Controllers (40) and a Mobile Switching Centre (50). The MSC 
(50) is also configured to act as a Service Switching Point SSP (50). The 
Base-stations (30) and the Base Station Controller together provide and 
control all radio transmission features. The Mobile Switching Centre 
controls call set-up and routing. A Home Location Register HLR (80) 
is a database storing subscribers' details notably each subscriber's 
location allowing uicoming calls to be delivered to subscribers. 

13 
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(70) is a Service Control Point (SCP). This is a standard element of an 
"Intelligent Network". It is a computer, which can tinder certain 
conditions control the processing of a telephone call by the Service 
Switching Point (50). The Service Control Point (70) is linked to the 
Service Switching Point (50) by an Intelligent Network AppUcation 
Part (INAP) signalling interface (60). 

(100) is the Payment Server. This contains multiple accounts for 
different users and has the means to transfer funds between different 
accounts. The Payment Server is coupled to the mobile network and 
also to the internet 24, and has a Web based user interface allowing any 
user with a web browser to configure options for their account e.g. 
whether a PIN must be entered for each transaction or a threshold level 
above which a PIN must be entered or whether the Payment Server 
should employ a two stage process with the user entering the details, 
the Payment Server echoing these back and the user then indicating 
acceptance by entering a PIN. The Payment Server also interacts with 
other web sites which the user is logging onto with their mobile phone. 

(110) is the Billing System of the mobile 'phone network. Each time the 
MSC/SSP (50) originates a call it creates a Call Detail Record (CDR) 
recording e.g. the dialled number, the call start time, the call end time 
etc. The Billing System (110) periodically collects these Call Detail 
Records (CDRs) and rates each call i.e. decides how much to tariff for 
each individual call. The tariff for a call is typically based on the 
dialled number (national, international), the time of day and the 
duration of the call. The tariff for the call may also be based on 

14 
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supplementary information inserted into the Call Detail Record by the 
Service Control Point (70). The SCP via the INAP interface has the 
ability to both modify and to add supplementary information to the 
CDR. 

(120) is a web site that is independent of the mobile network or the 
Payment Server, which a user may pay to visit as described with 
reference to figure 3. 

(130) is a Telecommunication Network. This may be either a mobile 
network, a PSTN, an ISDN or an titemet. This provides a 
communication channel between the Payment Server (100) and the 

Beneficiary Device. (140, 150, 160). 

140 is a device which may receive payment, e.g. a Cash Register (140), 
150 is a second device which may receive payment e.g. a Parking Meter 
(150) and 160 is a third device which may receive payment such as a 
vending dispensing machine. 

2.2.2 Making a payment between two nnobile 'phones 

The operation of this embodiment of the Invention will now be 
described. In the embodiment, in order for one user to make a 
payment to another the procedure is as follows. The Donor user dials 
a number composed of the following elements: 

• A Payment Service Access Code (e.g. 729). 

• the Beneficiary's telephone or account ntmiber (e.g. 0123 456 7891), 
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• the amount payable (e.g. 0 1525 i.e. $ 15.25 ) and 

• (optionally) the user's PIN number. 

When the user enters and dials this number the Mobile Network 
authenticates the Mobile Terminal (10) (to be more precise, it 
authenticates the Subscriber Identity Module inside the Mobile 
Terminal). This Authentication process proves that the calling mobile 
terminal (SIM) is in fact the Mobile Terminal (SIM) that it claims to be. 
This Authentication is vital to ensuring that subsequent Call Detail 
Records are assigned to the correct user's account. 

The numbers dialled by the Donor Mobile Terminal (10) are analysed 
by the MSC/SSP (50), which identifies the leading digits (729) as a 
Service Access Code. 

hi the preferred embodiment, the MSC/SSP (50) then sends a request 
to the SCP (70) via the INAP (60) interface. This signalling request 
contains the identity of the Donor Mobile Terniinal (its IMSI, or 
International Mobile Subscriber Identity) and the number dialled by 
the Donor Mobile Terminal (10). The signalling request also contains 
and implicit or explicit authentication of the Donor Mobile Terminal 
(10). The autiientication is at least implicit since the MSC/SSP (50) will 
only forward the request if the Mobile Terminal (10) is authentic. 
Alternatively tiie MSC/SSP may expUcitiy include an authentication 
field in the message. 

The SCP (70) then forwards the request for payment to the Payment 
16 
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Server (100). The Payment Server (100) then checks that the PIN 
number (if entered) is correct snd if so, if that the Donor (102) has 
sufficient ftmds (or stifficient credit) remaining in their account. If so 
then the Payment Server (100) transfers the funds from the Donor 
accoimt (102) to the Beneficiary account (104). Alternatively the 
Payment Server (100), rather than transferring funds between its 
internal accounts, may check the user's mobile 'phone account balance 
on either the SCP (70) or the Billing System (110) and instruct the 
relevant element to transfer funds between the Donor's mobile 'phone 
account (112) and the Beneficiary's mobile 'phone accotmt (114). As a 
further alternative the Payment Server (100) may transfer funds 
between either the Donor's or Beneficiary's account on the Payment 
Server and the other party's mobile 'phone account (112 or 114) using 
either the SCP (70) or the Billing System (110) as described previously. 
The Payment Server (100) may use any of the following alternatives: 
transfer funds between accounts maintained on the Payment Server 
(100) itself; transfer funds between an account on the Payment Server 
(100) and a mobile 'phone account either by using the Billing System or 
by instructing the SCP to modify the CDR that it produces in order to 
debit the specified amount from the Donor or to credit this to the 
Beneficiary; transfer funds between mobile 'phone accoimts either by 
utilising the Billing System or by instructing the SCP to modify the 
CDR that it produces in order to debit the specified amount from the 
Donor and to credit this to the Beneficiary 

The Payment Server (100) may then send a confirmation message to 
17 
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the Beneficiary Mobile Terminal (20) using either a text message, e.g. 
GSM Short Text Message (SMS), or a prerecorded Voice Clip. To 
provide the Beneficiary with proof/ reassurance that this confirmation 
message has in fact come from the Payment Server, the Payment Server 
(100) may append a secret Password or PIN number known only to the 
Beneficiary and the Payment Server. Thus when the Beneficiary 
receives a Payment Received message containing their secret 
Password, they can be assured that the message has come from the 
payment server and not from an impersonator. 

A refinement of this idea is to allow the Donor to specify the cturency 
of payment, by entering the international telephone coimtry code for 
the coxmtry in question ( e.g. since +33 is the country code for France, 
'729 1234 +33 15 SEND' means pay user # 1234 15 French Francs). 

A refinement of this procedure may be used to prevent "wrong 
numbers". If the MSC can supply the Identify of the Radio Base station 
from which the call is being made (Cell ID), then it is possible to 
configure the service to require that both parties to a transaction are in 
the same or adjacent cells, or in the same geographic area if a 
transaction is to be allowed to proceed. 

2.2.3 Alternative sequence of entering the numbers. 

There are several variations of the way in which the numbers may be 
entered. The user may configure whichever variation they prefer. The 
user may dial the Service Access Code only and then await a response 
(either a voice prompt or a text prompt (via SMS, USSD or WAP)) 

18 
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before entering the rest of the details. A third option is for the user to 
enter all the details except Ihe PIN ntunber. The Payment Server (100) 
then echoes the Payment Details back to the Donor Mobile Terminal 
(10) and the Donor enters their PIN number to confirm the transaction. 

2.2.4 Alternative Adjunct based implementation 

In an alternative aspect of the Invention, rather than using an IN 
architecture i.e. with an SSP (50) and SCP (70) and Service Access Code 
which is detected by the SSP, an external adjimct switch (190) is used. 

This approach is illustrated in figure 5 and may be used in 
circumstances either where the MSC does not have an SSP capability 
(i.e. the ability to trigger a signalling request to a SCP) or where the 
Operator of the Mobile network is unwiUing to provide this service. In 
this case the user dials a conventional telephone number e.g. 0900 123 
4568 that terminates on a SSP/SCP. Alternatively the user may dial a 
"star service code" eg. "*729" if the MSC has the ability to recogrrise 
"star" numbers and route this to an external telephone exchange which 
has the equivalent of the SSP/SCP functionality described previously. 
The user may ihen enter the number of the Beneficiary, the amotmt 
payable and the Donor's PIN number. The external telephone 
exchange may also provide facilities such as voice prompting to help 
the user conduct a transaction. 

The interface between the mobile network 22 (or an intermediate 
PSTN/ ISDN network) and the Adjunct switch (190) may be either a 
user-network interface or a network-network interface. If the interface 
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is a network-network interface i.e. one employing Signalling System 
No 7 then the Operator of the Adjimct Switch (190) will receive 
terminating call payments for calls made to the Adjunct Switch (190) / 
Payment Server (100). This allows the Operator of the Payment Server 
to in effect receive a transaction fee for providing callers with the 
ability to pay other users. The caller pays a standard mobUe call 
charge and does not have to pay a premitim call charge. 

2.2.5 Making a payment to an otfline device 

A further aspect of the Invention may advantageously allow payment 
to offline devices such as a Cash Register (140), a Parking Meter (150) 
or a Vending Dispensing Machine (160). As was described previously 
there are known methods of Automatic Vending using a mobile 
'phone. These use Premium Rate number services and suffer from the 
drawback that there is a fixed correspondence between the number 
dialled and the tariff. The present aspect of the Invention may allow 
complete flexibility for both the Beneficiary and the Amoimt payable, 
hi a preferred embodiment, to make a Payment to an offline Cash 
Register (140) the procedure is as follows. The Donor user dials the 
Service Access Code (e.g. 729), the Identity number of the Cash 
Register (e.g. 1234), the Amount payable and the donor's PIN number. 
As described previously the Donor Mobile Terminal (10) is 
authenticated and the funds transfers to the Beneficiary's Account 
(either 104 or 114 as appropriate). The Payment Server (100) may then 
send a Payment Confirmation message via the mobile network to a 
Mobile Terminal (135) connected to the Beneficiary Device (140). The 
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Mobile Terminal (135) relays the message to the Beneficiary Device 
(140). In alternative implementations the Beneficiary Device (150, 160) 
may be linked to the Payment Server (100) by another 
telecommunication network e.g. a PTSN, ISDN or Internet. 

In a variation of this idea the Beneficiary Telephone passing the 
Identity of the Base-station from which the call is being made in the 
INAP signalling message from the SSP to the SCP may shorten the 
Beneficiary identity nximber. This simpHfies the process for the Donor 
user. If no Cell Identity Information is passed then the Beneficiary 
must have a number, which is Nationally imique. On the other hand if 
Cell Identity information is passed, then the number need be unique 
only within the area served by that individual Radio Base Station. This 
allows for shorter Beneficiary Numbers and thus greater user 
convenience. 

To collect a receipt for the transaction, the user of the Donor mobile 
'phone may log onto the Payment Server (100) via the Internet and 
collect a Receipt. 

2.2.6 Proxy Authentication 

An important feature to notice about this aspect of the Invention is that 
it incorporates indirect or what might be termed "Proxy" 
Authentication. This makes tihe service much more secure than if the 
service were provided over say a PSTN/ISDN 'phone. This approach 
allows the security of the mobile network to be exploited by other 
external systems. 
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Figure 6 shows both conventional "direct" authentication and the 
novel form of indirect or proxy authentication. In figure 6 line (a) 
illustrates a direct authentication of the Subscriber Identitj^ Module 
(SIM) card 28. Similarly line (b) illustrates a direct authentication 
between a WAP / HTML browser in the mobile 'phone terminal (10) 
and a Visited WAP / Web site (120). By contrast hnes (c) and (d) show 
an indirect authentication. The user (SIM) is directly authenticated by 
the HLR (80), which in turn then either explicitiy or implicitly informs 
the SCP (70) that the user is authentic. The HLR (80) may inform the 
SCP (70) implicitly simply by permitting the caU to proceed (it would 
do this only if the user were authentic thus implying an 
authentication). The SCP (70) can then expUcitly or implicitly inform 
the Visited Third party web site (120) or the Payment Server (100) (not 
shown in figure 6) that the caUing user is authentic. 

Advantages of this indirect authentication mechanism include the 
following: 

• It is much more secure than using a fixed PSTN / ISDN 'phone, yet 

• It is not as complex as conventional mobile methods. It does not 
require a special/ advanced mobile 'phone, nor does it require 
complex mobile internet (WAP/CHTML etc) or SAT software in 
the 'phone / SIM. 

Logging onto web sites 

Another aspect of the Invention allows users to log onto web sites 
using their mobile 'phone and PIN number rather than a user name 
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and password. The operation of a preferred embodiment of this 
aspect of the Invention is as follows (with reference to figure 4): 

1) The User accesses the Internet using an Internet Access Device 
(170) and web browser. The user browses to a web site (120) 
which has joined the Payment Server Service. The user's 
browser downloads the log-on web page onto the user's 
screen. An example of a Log-on screen is illustrated in figure 3. 
This web page is composed of various elements one of which is 
a HTML hnk to the Payment Server (100). 

2) The embedded HTML link in the Log on dialogue page 
generates a HTTP link to Payment Server. This http request 
may also carry a cookie from user's Internet Access Device 
(170). A cookie is a well known technique and comprises a 
simple text file that contains a unique reference number that 
identifies an individual user. The cookie was written to the 
user's Internet Access Device by the Payment Server (100) on a 
previous visit to the Payment Server. 

3) The Payment Server generates a Reference Number for this 
user's log on request, and 

4) Sends this Log-on reference munber in a HTML message to the 
browser on the user's Internet Access Device (170) 

5) The browser formats and displays log-on dialogue box (e.g. 
figure 3) 
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6) The user dials the Service Access Code, the web site's reference 
number and their PIN number into their mobile 'phone (10). If 
the Web site charges a fee for accessing the site then the user 
may enter the amount payable. 

7) The MSC/SSP (50) identifies from the Service Access Code that 
this is a Payment Server call and triggers a query to the Service 
Control Point (70). The SCP (70) forwards the subscriber 
authorisation, the Calling Line ID, the web site reference 
number etc, to the Payment Server (100). 

8) The Payment Server (100) uses the Reference Number to match 
the incoming mobile caU with the web site log on request. 

9) If the mobile network has authenticated the user then the 
Payment Server (100) informs the third party web site (120) 
that the web-site visitor is accepted and the web site (120) 
allows the user to log on. Similarly if a fee is payable the 
Payment Server acknowledges to the Visited Web site that this 
has been credited to the Web Site's account. 

2.2.8 Paying for online goods. 

To pay for online goods the procedure is as follows. The user browses 
using an Intemet Access Device (170) to a web site where they decide 
to purchase goods. On the payment page they are presented with 
alternative payment mechanisms e.g. as illustrated in figure 7. 

If the user selects the pay by mobile 'phone option 101 then they are 
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presented with a dialogue box that instructs them to dial a number 
composed of the following elements: The Service Access Code, the 
Web Site reference niunber, the Amoimt payable and the user's PIN 
number. 

As described previously, the Reference Number displayed on the Web 
site (120) dialogue box is supplied using HTML references by the 
Payment Server (100). 

The user then dials the number indicated. As described above the 
Service Access Code is detected by the MSC/SSP(50) and triggers a call 
to the SCP(70). The SCP (70) then contacts the Payment Server (100) 
which then debits the Donor Mobile Terminal (10) account either (102 
or 112) . In either case the Payment Server informs the third party web 
site (120) that the transaction has been authorised. 

2.2.9 Purchasing Lottery tickets 

In another embodiment, the Invention may allow the purchase of 
lottery tickets. The procedure is as follows. The Donor user dials 
7295(PAYL) immediately followed by their chosen numbers e.g. 01 12 
17 18 20 40 immediately followed by their PIN number. 

The user may then be e-mailed a receipt. 

2.2.10 Sending business cards 

In another aspect of the Invention, the Donor User rather than sending 
funds n\ay send other information, such as a Business Card. In an 
embodiment of tius aspect of tihe invention, the Donor dials a different 
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Access Code say 2273 (for Card) then the Beneficiary's telephone 
number, and an Optional PIN foUowed by SEND. As described 
previously the Service Access Code triggers the MSC/SSP (50) which 
then passes the diaUed number to the SCP (70). The SCP (70) then 
signals to the Payment Server (100) to send an electronic business card 
to the Beneficiary's e-mail address or mobile 'phone. (If email is to be 
used, there is a pre-requisite that the Beneficiary has already registered 
their e-mail address.) 

Integrating with tlie Mobile Operator's billing system. 
In several of the example applications described thus far, the services 
have been described in the context of a system using a standalone 
Payment Server (100) i.e. where the Donor and beneficiary have 
accounts on the Payment Server (100). 

It would also be very convenient for many users if the funds could be 
debited directly from their mobile telephone bill. The conventional 
method of doing this would be to establish a proprietary 
communications link between the Payment Server (100) and the MobUe 
'Phone Billing System (110). However this type of approach presents 
some quite formidable implementation obstacles, which add 
substantial project delays and may even prevent the integration taking 
place at all. 

In an embodiment of a still further aspect of the Invention, the solution 
is to employ the mechanisms that are conventionally used only for 
billing calls made by International Roaming mobiles or alternatively 
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the mechanisms used for billing a directly mtercoimected Operator. 
These mechanisms are briefly summarised in Section 1.1.6. There are 
two mechanisms for billing International Roamers, one for "post paid" 
or "credit" customers and one for "pre-paid" or "debit" customers. 
These techniques are well known. In either case the basic idea is the 
same, namely to use these mechanisms to create and send to the 
Mobile Operators a set of Call Detail Records, where the Records 
rather than referring to telephone caUs refer to other products and 
services e.g. Parking Meter charges, vending machine charges etc. 

The major advantage of tiiis approach is that the Mobile Operator does 
not need to alter any of their existing systems and procedures. This 
reduces delays and other obstacles to implementation. 
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3 



Claims 



1. Generic Payment service accessed either by full telephone number 
or by shortened Service Access Code (IN) then enter beneficiary, 
amotmt and PIN. 

2. Payment by dialled digits structured in the form: Service Access 
Code, Beneficiary Number/code, Amount, PIN number. 

3. User can specify destination beneficiary by specifying telephone 
number. 

4. User can specify amount payable by entering digits. 

5. User can specify payment currency by using International Country 
Code. 

6. Make a payment between two mobile 'phones using a service 

access code. 

7. Generic Service Access code, invoking IN SCP node in mobUe 
network and thus Pajonent Server. 

8. Payment alternatively performed in two stages. In two stages: (a) 
Donor dials "729, Beneficiary #, Amount SEND", (b) Donor then 
receives confirmation of payment amount and is prompted to enter 
PIN. Donor then confirms by dialling X X X X (PIN) SEND. 

9. In two separate stages, 729 SEND, Beneficiary, PIN 
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10. HLR provides proxy Authentication service to third party web 
sites. 

11. Use of Adjunct switch and network-network interface to gain 
transaction charge for transactions made on Payment Server. 

12. Use of Cell Location Information to allow shorter codes. 

13. Use of Cell Location to prevent wrong numbers. Both users must 
be in the same Cell. 

14. Make offline payments using mobile 'phone. Linking a mobile 
'phone to a cash register to allow payment to be registered at the 
cash register. 

15. Appended PIN/Password to verify source of Payment Received 
message. 

16. Use of Location Information to allow the use of shorter Beneficiary- 
identification numbers. 

17. Logging onto web site by means of a number dialled onto a mobile 
phone rather than by entering a user name and password. 

18. Paying for access to a web site by means of a a number dialled onto 
a mobile phone. 

19. Paying for goods online by means of numbers dialled into a mobile 
'phone. 

20. Sending business cards by mobile 'phone. 
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